Copyright: DumpAcl Copyright ® 1994 Somar Software


DumpAcl Help Contents
Somar DumpAcl (TM) Version 1.1 Help Contents

Copyright © 1994 Somar Software

Overview

Installation

Uninstallation

Known bugs and limitations

Notes on Using

Directory tree report

Registry hive report

Copyright/License/Warranty Disclaimer

Registration

Security notes


Overview of DumpAcl
Overview

Somar DumpAcl is a Windows-NT program that will dump the permissions (ACLs) for the file system and registry in a concise, readable listbox format, so that "holes" in system security are readily apparent. Somar DumpAcl is a must-have product for Microsoft® Windows NT (TM) and NTAS (TM) systems administrators.

Windows NT contains the mechanisms for providing strong system security, using permissions (a.k.a. access control lists or ACLs) to control access to files and registry keys. However, it can be very difficult to determine if all permissions have been set correctly, since there are so many files and registry keys on the typical system. The situation is analogous to having a building with unbreakable locks on each of 10,000 doors. The problem is not with the locks themselves, but rather with one person walking around on a regular basis and checking that none of the 10,000 doors is unlocked.

Somar DumpAcl provides a solution to the problem of too many files and registry keys to check on a regular basis, by producing a concise and readable report of file system or registry permissions. By reviewing this report, you can determine if users have more access to the file system or registry than you want to allow. You can then use file manager or the registry editor to set permissions differently.

Some users have suggested just setting permissions on the root directory or registry key (e.g. C:\ or HKEY_LOCAL_MACHINE) and letting those permissions be propagated to all child directories/files/keys. In general, however, it is not acceptable for all directories, files and/or registry keys to have the same permissions. In fact, trying to make all permissions the same may prevent Windows NT from running properly.

See Security notes for further general discussion of computer security.


Installation

1) Place DUMPACL.EXE and DUMPACL.HLP together in any directory.

2) The first time DUMPACL.EXE is run, it will create the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\SomarShareware\DumpAcl

3) Somar DumpAcl makes no other changes to your system.


Uninstallation

1) Run DUMPACL.EXE with "/u" as a command line parameter. If successful, a message box will be displayed indicating that the SomarSoftware\DumpAcl registry key has been deleted.

2) Delete DUMPACL.EXE and DUMPACL.HLP from your computer.


Known bugs and limitations

1) Somar DumpAcl currently does not support Unicode. Somar DumpAcl will be Unicode enabled as soon as MFC (Microsoft Foundation Classes) is Unicode enabled.

2) Somar DumpAcl does not indicate whether directory permissions are inheritable. File manager always makes directory permissions inheritable so this is not a severe limitation. That is, of the permissions in the list below, type (b) is always the same as (a), if you used File Manager to set file system permissions:

a) Permission applies to directory itself (Dir column of Somar DumpAcl report)

b) Permission will be inherited by newly created subdirectories in directory (not shown by Somar DumpAcl)

c) Permission will be inherited by newly created files in directory (File column of Somar DumpAcl report)


Notes on using

1) When generating a report for a registry hive, you can optionally specify a remote compute (HKEY_LOCAL_MACHINE and HKEY_USERS hives only). If the computer name field is left blank, the local registry will be used.


Directory tree report

Somar DumpAcl shows as little of the file system as possible. Permissions for a subdirectory are the same as for the parent directory, unless the permissions for the subdirectory are explictly shown. Permissions for all files in a directory are the same as the permissions in the file column of the directory, unless the permissions for the file are explictly shown. The containing directory is shown for any file that is shown, even if this directory has the same permissions as its parent directory (this is done to improve readability). The CREATOR OWNER account is ignored in comparisons of permissions, since this pseudo-account is converted to the account of the user who creates a file in a directory.

Dir column (used for directories only)

R	account can list the contents of the directory

W	account can add new files and subdirectories to the directory

X	account can traverse the directory as part of a path

D	account can delete the entire directory

P	account can change permissions for the directory and all files and subdirectories

O	account can change the directory owner

all	same as RWXDPO

no access	account is denied all access to directory

Axhhhhhhh 	non-standard allow permissions, see WIN32 SDK documentation

Dxhhhhhhh 	non-standard deny permissions, see WIN32 SDK documentation

==>access denied	cannot read the permissions for the directory

File column (used for directories and files)

For files, this column lists the permissions that apply to the file. For directories, this column lists permissions that will be inherited by files created in the directory, unless the creator of the file explicitly specifies other permissions.

R	account can read the file

W	account can write to the file

X	account can execute the file

D	account can delete the file

P	account can change permissions for the file

O	account can change the file owner

all	same as RWXDPO

no access	account is denied all access to file

Axhhhhhhh 	non-standard allow permissions, see WIN32 SDK documentation

Dxhhhhhhh 	non-standard deny permissions, see WIN32 SDK documentation

==>access denied	cannot read the permissions for the file

Own column

Contains an "o"  if this account is the owner of the directory or file, and blank otherwise.

Example:

Path                         Account         Own Dir        File

c:\SPECIAL\                  Administrators   o  All        All

c:\SPECIAL\                  Everyone            R X        R X

c:\SPECIAL\                  CREATOR OWNER                  All

c:\SPECIAL\                  SYSTEM              All        All

c:\SPECIAL\JUNK\             Administrators   o  All        All

c:\SPECIAL\JUNK\             Everyone            R X        R X

c:\SPECIAL\JUNK\             CREATOR OWNER                  All

c:\SPECIAL\JUNK\             SYSTEM              All        All

c:\SPECIAL\JUNK\junk.txt     Administrators   o             All

c:\SPECIAL\JUNK\junk.txt     Everyone    	                  R X

c:\SPECIAL\JUNK\junk.txt     SYSTEM                         All

All directories and files under C:\SPECIAL\ have the same permissions as listed for C:\SPECIAL\, except for the C:\SPECIAL\JUNK\junk.txt file. Note that C:\SPECIAL\JUNK\ is shown even though it has the same permissions as its parent directory, C:\SPECIAL\. This is because C:\SPECIAL\JUNK\junk.txt is shown, and the containing directory of a file that is shown is also shown, to improve readability.


Registry hive report

Somar DumpAcl shows as little of the registry hive possible. Permissions for a subkey are the same as for the parent key, unless the permissions for the subkey are explictly shown. The Key column shows the permissions for the key itself. The Inheritable column shows the permissions that will be inherited by new subkeys created under the key, unless the creator of the subkey explictly specifies other permissions.

Permissions

Q	account can query values for the key

S	account can create or set values for the key

C	account can create sub keys under the key

E	account can enumerate sub keys under the key

N	account can request notification whenever the key changes

L	account can create a registry link

D	account can delete the key

P	account can change permissions for the key

O	account can change the key owner

R	account can read the permissions for the key

read	same as QENR

all	same as QSCENLDPOR

no access	account is denied all access to key

Axhhhhhhh 	non-standard allow permissions, see WIN32 SDK documentation

Dxhhhhhhh 	non-standard deny permissions, see WIN32 SDK documentation

==>access denied	cannot read the permissions for the key

Own column

Contains an "o"  if account is the owner of the key, and blank otherwise.

Example:

Path                    Account         Own Key        Inheritable

HKEY_CURRENT_USER       SYSTEM              All        All

HKEY_CURRENT_USER       Administrators   o  All        All

HKEY_CURRENT_USER       Frank               All        All

HKEY_CURRENT_USER\Junk  Administrators   o  All        All

HKEY_CURRENT_USER\Junk  SYSTEM              All        All

All keys under HKEY_CURRENT_USER have the same permissions as listed for HKEY_CURRENT_USER except for the HKEY_CURRENT_USER\Junk key and its subkeys.


Copyright/license/warranty
Copyright/License/Warranty Disclaimer

Somar DumpAcl (TM) is Copyright © 1994 Somar Software, All rights reserved.

Send problem reports and other comments to 72202.2574@compuserve.com.

License Agreement and Warranty Disclaimer

You should carefully read the following terms and conditions before using this software.  Use of this software indicates your acceptance of these terms and conditions.  If you do not agree with them, do not use the software.

Shareware Version

You are hereby licensed to: use the Shareware Version of the software for a 21 day evaluation period; make as many copies of the Shareware version of this software and documentation as you wish; give exact copies of the original Shareware version to anyone; and distribute the Shareware version of the software and documentation in its unmodified form via electronic means. There is no charge for any of the above.

You are specifically prohibited from charging, or requesting donations, for any such copies, however made; and from distributing the software and/or documentation with other products (commercial or otherwise) without prior written permission, with one exception: Disk Vendors approved by the Association of Shareware Professionals are permitted to redistribute Somar DumpAcl, subject to the conditions in this license, without specific written permission.

You are specifically prohibited from copying or redistributing the keyfile (DUMPACL.KEY) that will be sent to you upon receipt of your registration payment.

Unregistered use of Somar DumpAcl after the 21-day evaluation period is in violation of United States and International copyright laws.

For how to register, see Registration.

A single registered copy of Somar DumpAcl can only be installed on a single computer. Thus, if you have 3 computers on which you want to install Somar DumpAcl, you must register and pay for 3 copies of Somar DumpAcl.

Governing Law

This agreement shall be governed by the laws of the District of Columbia.

Disclaimer of Warranty

THIS SOFTWARE AND THE ACCOMPANYING FILES ARE SOLD "AS IS" AND WITHOUT WARRANTIES AS TO PERFORMANCE OF MERCHANTABILITY OR ANY OTHER WARRANTIES WHETHER EXPRESSED OR IMPLIED. BECAUSE OF THE VARYING HARDWARE/SOFTWARE ENVIRONMENTS INTO WHICH SOMAR DUMPACL MAY BE PUT, THERE IS NO WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE.

GOOD DATA PROCESSING PROCEDURE DICTATES THAT ANY PROGRAM BE THOROUGHLY TESTED BEFORE RELYING ON IT. THE USER MUST ASSUME THE ENTIRE RISK OF USING THE PROGRAM. ANY LIABILITY OF THE SELLER WILL BE LIMITED EXCLUSIVELY TO PRODUCT REPLACEMENT OR REFUND OF PURCHASE PRICE.


Registration

This is not free software. This license allows you to use this software for evaluation purposes without charge for a period of 21 days.  If you use this software after the 21 day evaluation period a registration fee of $25 is required. Payments must be in US dollars drawn on a US bank,  payable to Somar Software, and sent to Somar Software, 1 Scott Circle, NW Suite 816, Washington, DC 20036, USA. You can also register through CompuServe (GO SWREG, ID 2723).

Upon receipt of your registration payment (check or CompuServe notice), you will be sent a key file (DUMPACL.KEY), which is to be placed in the same directory as DUMPACL.EXE. This key file will be your proof of registration. The presence of this key file will enable certain functions of Somar DumpAcl which are disabled in the unregistered version. These functions involve the ability to produce hardcopy printouts of the Somar DumpAcl report.

Somar Software reserves the right to increase the registration fee at any time without notice. If the fee has been increased, and your payment is received after such increase, then Somar Software has the right to require additional payment before accepting your registration and sending you a key file. Once you have paid the then current registration fee, and Somar Software has accepted your fee and sent you a key file, you have the right to use the version of Somar DumpAcl that you paid for, for as long as you want, without additional payment. Future versions of Somar DumpAcl may require a different key file. You may be required to pay an additional fee to upgrade to such future versions.

A single registered copy of Somar DumpAcl can only be installed on a single computer. Thus, if you have 3 computers on which you want to install Somar DumpAcl, you must register and pay for 3 copies of Somar DumpAcl.

You may access the registered version of Somar DumpAcl through a network, provided you have obtained individual licenses for the sotware covering all workstations that will access the software through the network.


Security notes

What is security?

A secure system is one that is protected against various natural disasters and human attacks. Security with respect to a computer system is very similar to security with respect to a bank vault. A computer system or bank vault containing valuables (data in the case of a computer system, secret documents or jewels in the case of bank vault) is secure if:

1) No one can look at, modify or remove any of the valuables for which they do not have the proper authority. In the computer context, this requires:

Permissions are set properly.

Computer is physically secured, possibly inside a locked room.

Data is encrypted if computer cannot be physically secured (e.g. portable PC).

Backup tapes are physically secured in a safe, or else encrypted.

There are procedures in place to ensure viruses do not get introduced into the system.

2) No person or natural disaster such as a fire can easily destroy the valuables. In the computer context, this requires:

Permissions are set properly.

Backups are performed regularly.

Copies of backup tapes are stored offsite.

There are procedures in place to ensure viruses do not get introduced into the system.

3) No one can easily disrupt authorized access to the valuables. In the computer context, this requires:

Permissions are set properly.

There are procedures in place to ensure viruses do not get introduced into the system.

An example of disrupting authorized use of a computer system is a virus that modifies and thereby corrupts the registry so a database program will not run. The database itself maybe intact (because it was protected by permissions), but the data cannot be accessed until the registry is repaired, which may require reinstalling the database program. This temporary disruption can be as costly as actual loss of data for many mission critical computer systems.

Note the importance of permissions and viruses, which are implicated in all types of security risks. Permissions are the primary protection against malicious users and viruses which run under user accounts. There is no way to protect against viruses which run under administrator or system accounts. So it is very important to avoid running untrusted programs when logged on as an administrator, or to allow untrusted program to be run as services under a system or administrator account.

What should a well-organized set of file system permissions look like?

A well-organized set of file system permissions will produce a short Somar DumpAcl report. In general, the shorter the report produced by Somar DumpAcl, the easier to understand, and so the more confident the systems administrator will be that permissions have been set properly.

What is wrong with the Windows-NT Version 3.1 registry key permissions?

Use Somar DumpAcl to produce a report of the HKEY_LOCAL_MACHINE registry hive. Note that Everyone has write and delete access to many keys. So any user who can access the registry locally or remotely can make changes that might disrupt system operations (type 3 security breach, as described above) and possibly obtain unauthorized access files (type 1 and 2 security breach). Neither I nor anyone I have discussed this issue with seems to understand the registry well enough to definitely state what the potential for mischief is in allowing Everyone to have write access to so many registry keys. No one seems to know whether this access can be taken away, or whether doing so will cause problems with the normal operation of Windows-NT. The registry key permissions seem to have been set in a very haphazard and inconsistent way. Only Microsoft can clean this mess up and even for them it will no doubt be a considerable effort, since each piece of the registry is probably the responsibility of a different group of programmers.